Projet Zuul de conception orientée objet en Java d'un jeu d'aventure
Forum des exercices du projet Zuul
Exercice 7.7
Abonné
- Make a similar change to the printLocationInfo method of Game so that the details of the exits are now prepared by the Room rather than the Game.
- Define a method in Room with the following signature public String getExitString() .
- Comprenez-vous pourquoi il est logique de demander à Room de produire les informations sur ses sorties (et ne pas lui demander de les afficher), et pourquoi il est logique de demander à Game d'afficher ces informations (et ne pas lui demander de les produire) ?
Un étudiant a écrit :
Quelle est la différence entre getExit et getExitString? (je ne comprends pas l'utilité de mettre l'une sous fome de room et l'autre de string)
Ces deux méthodes appartiennent à la classe Room et doivent donc être appelées sur un objet Room (par exemple, la cuisine).
1) getExit possède un paramètre String qui permet de lui passer une direction ; elle nous retourne donc la Room qui se trouve dans cette direction (à partir de la cuisine, dans notre exemple).
2) getExitString (sans paramètre) doit retourner la String contenant la liste de toutes les sorties de la pièce (dans notre exemple, la cuisine).
Un étudiant a écrit :
Bonjour Monsieur,
Je ne comprend pas bien comment on doit faire pour préparer printLocationInfo avec la méthode getExitString de la classe Room étant donné qu'on a besoin de aCurrentRoom qui est un attribut privé de la classe Game.
Doit-on rendre cet attribut public ?
Pour votre dernière question, la réponse est définitivement NON : les attributs doivent TOUJOURS rester privés.
L'attribut aCurrentRoom de Game n'est nullement nécessaire dans getExitString : cette méthode appartient à la classe Room et pourra donc être appelée sur n'importe quel objet Room (par exemple, sur aCurrentRoom dans printLocationInfo).
Un étudiant a écrit :
retourner une String contenant les sorties de la pièce couranteJ'aurai une question concernant la méthode getExitString().Je ne comprends pas bien son rôle
getExitString n'est pas getExitStrings !et surtout comment retourner plusieurs string à la fois.
ce qu'on doit retourner, c'est une seule String !
(et non pas une String pour chaque sortie)
Mais c'est ce que fait printLocationInfo, et on vous explique justement pourquoi ce n'est pas bien ...Le code que j'ai écris permet de retourner uniquement une seule et unique sortie. Pourquoi ne pas créer cette fonction sans aucune valeur de retour et ne pas utiliser System.out.println pour afficher les sorties ?
1) Une raison de logique
- Qui est mieux placée que la Room pour savoir quelles sont ses sorties ?
- Pourquoi serait-ce à Game d'aller fouiller à l'intérieur d'une Room pour découvrir ses sorties ?
- Par contre, ce n'est pas à Room de décider quoi faire avec la String des sorties.
- Game peut décider de l'afficher dans le Terminal ou dans une fenêtre graphique par exemple.
2) Une raison technique
- Les attributs doivent maintenant être privés, comme tous les attributs.
- Seule Room y a donc accès, donc pas Game !
J'ai une question concernant la fonction getExitString() :
Un
return peut renvoyer qu'un seul String à la fois ce qui m'amène à
traiter les 2^4 = 16 possibilités. Est ce la méthode attendu ou il y a
plus simple/rapide ?
Un étudiant a écrit :
Le message d'erreur signifie qu'il n'existe pas de méthode getExitString dans la classe courante : donc, dans quelle classe écrivez-vous l'appel et dans quelle classe est définie cette fonction ?
Posez-vous la question : je souhaite obtenir la String des sorties de quoi ?
Ensuite, il ne vous restera qu'à écrire quoi.getExitString() !
Un étudiant a écrit :
j'ai réussi tout les exercices demandés jusque là et je suis à
l'exercice 7.7.
Cet exercice me demande de changer la plus part de mon code qui
marche.
Est il essentiel de changer son code afin d'en faire un plus
court ou je peux garder mon code ?
J'ai passé du temps à expliquer lors des 2 premiers cours de l'unité
que le projet alternait ajout de fonctionnalité et
récriture du code pour en améliorer la programmation.
Le but n'est pas que votre code marche, mais qu'il soit bien écrit,
donc qu'il marche et qu'il soit aisément extensible.
De plus, la question que vous posez tend à montrer que vous n'avez pas
compris
les explications du livre sur la cohésion et le couplage.
En résumé oui, vous devez faire les exercices qu'on vous demande de faire,
et celui-là en particulier.
Un étudiant a écrit :
En comparant mon projet à Zuul-better (exercice 7.18.1), je remarque que ma fonction
getExitString est bien plus simple que celle de zuul-better.
En effet je n'utilise pas de for each mais la fonction keySet() suivie
de toString().
Voici mon code :
public String getExitString()
{
return exits.keySet().toString();
}
Au final le résultat est pratiquement le même : mon projet "affiche" les
sorties comme ceci "[sortie1] [sortie2], etc" et zuul-better "affiche"
les sorties comme cela "sortie1 sortie 2 etc".
Est-ce "grave" ?
Pour la fonctionnalité du jeu, je suis bien obligé de répondre : Non, ce n'est pas grave.
Pour le respect du cahier des charges, ça l'est un peu plus : vous devez afficher les sorties séparées par des espaces, sans virgules ni crochets.
Enfin, pour votre apprentissage de Java (ce qui, je le
rappelle, est le but de ce projet), c'est "grave", puisque vous n'aurez
pas appris à vous servir de la boucle for each et de la construction progressive d'une String.
Activer le mode édition
Paramètres
Utilisateurs inscrits
Groupes
Voir les permissions
Autres utilisateurs
Filtres
Rapport des compétences
Notes
Sauvegarde
Restauration
Importation
Réinitialiser
Compétences
Enseignant non éditeur
Réseaux sociaux